The provisioning of devices within a high-bandwidth communications network infrastructure is a non-trivial exercise. Each time a new device or network node (“node”) such a router, switch, gateway, or other network device is introduced into a network, the node needs to be configured with sufficient information such that it can start offering services. This type of initial configuration typically requires the involvement of a network engineer and is open to errors, including typos, address mismatches, etc. Although various existing tools may automatically provision an IP address and a gateway IP address for a node, this type of automated solution merely satisfies the reachability requirement for a device. Although reachability may be adequate for provisioning a termination device, end device, or customer premises equipment (“CPE”) (for example a DSL modem, or E-UTRAN Node B in mobile networks (“eNB”, also known as Evolved Node B), etc.) it is insufficient to prepare a node to provide most services offered by service providers, which usually require greater interoperability with other network nodes, and also typically have higher bandwidth requirements.
In such applications, many settings beyond reachability must be configured to achieve operability, including, for example, assignation of a form of interior gateway routing protocol (for example, Open Shortest Path First (OSPF), Intermediate System to Intermediate System (ISIS), Routing Information Protocol (RIP), etc.), remote manageability (e.g., via an Element/Network Manager (EMS or NMS) or a software-defined network (SDN) Controller), transport network configuration (for example, Multiprotocol Label Switching (MPLS) or Internet Protocol/Generic Routing Encapsulation (IP/GRE)), etc. In conventional configurations, these settings typically must be configured manually by a network engineer before the node may be ready to accept service definitions, after which the node may actually start offering services.
Some attempt has been made at avoiding manual configuration by creating and applying offline templates to nodes once the reachability requirement has been satisfied. However, such offline template creation likewise requires intensive manual work by a network engineer, and is similarly open to errors. As an example, when creating a template for Interior Gateway Protocol (IGP), the number of different parameters that must be selected and configured can easily be overwhelming, (for example, area id, preference, metric, authentication method, area-type, etc.)
Additionally, this type of offline template creation requires a thorough understanding of the functionality of the existing network and the underlying network topology—for example, knowledge of the type of node being installed and which other network nodes will have existing configurations usable for that type—and constant updating—every time there is a change in topology, which is common, templates must be reviewed and revised. Also, there are no standardized offline template creation tools, hence a network administrator wishing to create a template typically must access an existing node, download its configuration to a text file, and manually edit the document as described above. Because there is no error check mechanism, each new template must be uploaded to a node to check for errors. Such an error check only offers sanity check against known errors but can never verify if the configuration is relevant, correct and appropriate for a given section of the network.
Some existing implementations make use of a “satellite” solution to quickly bring up nodes throughout a network/area/region. A satellite solution basically treats each and every remote node as a line card on an extended chassis such that they do not need to be individually configured within their own chassis one at a time. In a satellite model, all user data from remote nodes, i.e. satellites, are backhauled/switched to a centralized or hub node and bound to services. Such a solution wastes bandwidth for any-to-any traffic flows (i.e. ×2 traffic in 4G/LTE) because all traffic is switched through the HUB node. Also, masquerading remote/satellite nodes from network operators may not be well received by all network operators, because when a whole node is treated like a remote-line card, physical components are masqueraded, turning the whole node into a black box from the standpoint of network operators—the visibility to individual components is significantly reduced, obfuscating the status of individual physical building blocks behind the operator's network. Furthermore, in such a configuration, performance metrics including delay, jitter and loss for various service types becomes hard to implement and support. Finally, such a satellite solution also requires extremely robust dedicated processing and bandwidth at the hub location. Therefore, although a satellite implementation may reduce provisioning costs for individual nodes, it does not lower the total cost of ownership due to high costs associated with the hub node and bandwidth overhead. Such a solution may be suited for a limited subset of network topologies such as hub and spoke topologies with extensive fiber build out where the transport network is owned by the same Service Provider, but more distributed alternatives, like partial-mesh or rings, introduce expensive problems including delays in communication between the hub and satellite nodes further away in the ring; furthermore, because the subset of applications is limited, the additional cost of satellite solutions outweighs its benefits.